Release notes 2023

2023r10

Fix for transmission durations longer than 99:99:99 in linear schedule API

Previously, when using the linear schedule API and a POST /transmissions call would be sent with the following body including a duration higher than 99:99:99,

{
  "title": "Film",
  "transmissionId": "1234567",
  "channel": "MGX",
  "startDate": "2024-05-12",
  "startTime": "14:00",
  "duration": "100:99:99",
  "announcedTime": "14:00"
}

the following error response would be shown:

{
    "statusCode": "422",
    "message": "Operation cannot be completed due to violations",
    "timestamp": "2023-05-10T09:45:35Z",
    "concept": "Transmission",
    "id": "1234567",
    "errors": [
        {
            "errorCode": "CORE-00002",
            "description": "Parsing error. Use format:[hh]:[mm], [hh]:[mm]:[ss]",
            "data": [
                "100:99:99"
            ]
        }
    ]
}

However, when you would enter this number in the transmission plan, it would be accepted and converted to the correct hours, minutes and seconds, for example 101:40:39.

This issue has been fixed. When a body with a duration higher than 99:99:99 is sent now, the duration is accepted and also converted correctly.

2023r3

Fix for HH:MM:SS format in POST /fullDays call of linear schedule API

Since the previous version, it is possible to use both HH:MM and the HH:MM:SS formats for the startTime and announcedTime attributes in the PUT /transmissions and POST /transmissions and /fullDays calls of the linear schedule API.

However, when using the HH:MM:SS format in the POST /fullDays call, the old error response would still be returned:

{
    "statusCode": "422",
    "message": "Operation cannot be completed due to violations",
    "timestamp": "2023-02-22T13:57:32Z",
    "concept": "Transmission",
    "id": "5655715812",
    "errors": [
        {
            "errorCode": "CORE-00002",
            "description": "Parsing error. Use format:[hh]:[mm]",
            "data": [
                "10:00:20"
            ]
        }
    ]
}

This issue has been fixed. The HH:MM:SS format is now also accepted in this call.

2023r2

Live in POST /fullDays call of linear schedule API

Previously, in the linear schedule API, the live attribute was already available in the GET, PUT, POST /transmissions call.

From this version, it can also be added to the POST /fullDays call.

It maps to the Should be live check box on a transmission.

{
  "channel": "MGX",
  "scheduleVersion": "Active",
  "date": "2023-02-22",
  "transmissions": [
    {
      "template": "TX",
      "title": "NEWS",
      "transmissionId": "123456789",
      "startTime": "19:00",
      "duration": "60:00",
      "announcedTime": "19:00",
      "productCode": "NEWS1",
      "contentId": "987654321",
      "live": "true",
      "publicationRecord": {
...

A new version of the YAML should be retrieved to use the new attribute. This can be done via the GET /api call.

Start time and announced time in HH:MM:SS format in linear schedule API

Previously, the startTime and announcedTime attributes in the linear schedule API only supported times entered in the HH:MM format. These attributes could be used in the GET, PUT and POST /transmissions calls and POST /fullDays call.

If another format was used, such as HH:MM:SS, then the following error code was returned:

{
    "statusCode": "422",
    "message": "Operation cannot be completed due to violations",
    "timestamp": "2023-02-22T13:57:32Z",
    "concept": "Transmission",
    "id": "5655715812",
    "errors": [
        {
            "errorCode": "CORE-00002",
            "description": "Parsing error. Use format:[hh]:[mm]",
            "data": [
                "10:00:20"
            ]
        }
    ]
}

From this version, it is possible to use both HH:MM and the HH:MM:SS formats.

In the PUT /transmissions and POST /transmissions and /fullDays calls, the startTime and announcedTime attributes will accept either format.

{
    "title": "FFG 2020 - Kajillionaire",
    "transmissionId": "5655715812",
    "channel": "MgX",
    "scheduleVersion": "Active",
    "template": "Tx",
    "startDate": "2024-07-20",
    "startTime": "10:00:20",
    "duration": "01:00:00",
    "announcedTime": "10:00"
}

If the format HH:MM is used, then the seconds will default to 0.

For example, "startTime": "10:00" will be translated to 10:00:00 in HH:MM:SS format.

In the GET /transmission and /transmissions?filter calls, the startTimeWithSeconds and announcedTimeWithSeconds attributes have been added to the response.

They will show the start time and announced time in the HH:MM:SS format while the existing startTime and announcedTime attributes will show them in the HH:MM format.

{
    "title": "FFG 2020 - Kajillionaire",
    "transmissionId": "5655715812",
    "channel": "MgX",
    "scheduleVersion": "Active",
    "template": "Tx",
    "startDate": "2024-07-20",
    "startTime": "10:00",
    "startTimeWithSeconds": "10:00:20",
    "duration": "01:00:00",
    "announcedTime": "10:00",
    "announcedTimeWithSeconds": "10:00:00",
    "contentId": "3611445527"
}

A new version of the YAML should be retrieved to use the new attributes. This can be done via the GET /api call.

Check on frame rate transitions in linear schedule API

Since the previous version, it has been possible to define frame rate transitions on linear channels. (RN-5387) A frame rate transition indicates from what date the channel will work with another frame rate.

In the POST /transmissions and /fullDay and PUT /transmissions calls of the linear schedule API, the template attribute can be used to create transmissions using a transmission prototype.

Previously, whether or not the Transmission frame rate of the prototype matched the frame rate of the channel was already checked. (RN-5092) When a template was specified with a different frame rate, the following error code would be returned:

{
    "statusCode": "422",
    ...
    "errors": [
        {
            "errorCode": "LINEARSCHEDULE-00011",
            "description": "Transmission prototype: Tx is not valid for channel: MgX",
            "data": [
                "Tx",
                "MgX"
            ]
        }
    ]
}

Now, with the frame rate transitions, one channel can have different frame rates depending on the broadcast day.

Therefore, from this version, the frame rate of the transmission prototype provided in the call is checked against the frame rate that is applicable for the broadcast date, based on the frame rate transition.

For example, the frame rate of the channel is 25FPS but from 01/03/2023, a frame rate transition exists to switch to 50FPS as the planning frame rate. When I create a transmission on 28/02, the frame rate of the prototype should be 25FPS. When I create one on 01/03, the frame rate of the prototype should be 50FPS.

When the frame rates of the prototype and date match, the transmission is created. When they do not, an error code is returned with the prototype, frame rate and broadcast date.

For example, with the settings from the example above, I create a transmission with a prototype of 25FPS. This is allowed on 24/02 but when I create it on 03/03, it is not valid. The following error is returned 

{
    "statusCode": "422",
    "message": "Operation cannot be completed due to violations",
    "timestamp": "2023-02-23T10:23:14Z",
    "concept": "Transmission",
    "id": "TxBAPI",
    "errors": [
        {
            "errorCode": "LINEARSCHEDULE-00032",
            "description": "Frame rate: 25fps on transmission prototype: TxFR is not valid on date: 3 March 2023 for channel: MgX",
            "data": [
                "25fps",
                "TxFR",
                "3 March 2023",
                "MgX"
            ]
        }
    ]
}

When a POST or PUT call is sent to move a transmission to a date with a different frame rate, the same error message is returned.

For example, I created a transmission with a prototype of 25FPS on 24/02. The frame rates switches to 50FPS on 01/05. When I send a PUT call to move the transmission to  05/05, the frame rate is not valid so an error code is shown and the transmission is not moved.

Fix for head title in GET /transmissions call of linear schedule API

In a previous version, a fix was done in the GET /transmissions/:transmissionId: call to return the head title of a transmission for the title attribute.

However, in the GET /transmissions (search) call, the title attribute still returned the Title of a transmission.

This issue has been fixed. In this call, the head title is also returned.

Fix for incorrect body of POST /fullDays call in linear schedule API

Previously, when using the linear schedule API, the service would crash when sending a POST /fullDays call with the following body:

[
    {
    "title": "FFG 2020 - Kajillionaire",
    "transmissionId": "5655715812",
    "channel": "MgX",
    "scheduleVersion": "Active",
    "template": "Tx",
    "startDate": "2024-07-20",
    "startTime": "10:00",
    "duration": "01:00:00",
    "announcedTime": "10:00",
    "contentId": "3611445527"
    }
]

The crash happened because the body was not configured correctly as a JSON body.

This issue has been fixed. When an incorrect body is sent, the following error is returned:

{
    "statusCode": "422",
    "message": "Operation cannot be completed due to violations",
    "timestamp": "2023-02-23T11:16:17Z",
    "concept": "Full day import",
    "id": null,
    "errors": [
        {
            "errorCode": "LINEARSCHEDULE-00033",
            "description": "The JSON body must be a JSON object",
            "data": []
        }
    ]
}